Use of an encryption device in sending information is a known technique to prevent unauthorized parties being able to gain access to the information. Also in sending information over the Internet this is utilized. In the most simple processes this involves transmission between two apparatuses, further called A and B, with A acting as sending apparatus and B as receiving apparatus. Briefly stated, encrypting ensures that the recipient alone can read the message. It provides certainty to the sender that the message can actually be read by the recipient alone. This is done in asymmetric encryption systems by encrypting the message with the public key of the recipient. The recipient alone can decrypt the message with his private key. Encrypting hence does not provide certainty to the recipient that the message originates from the sender (anyone can encrypt with the public key of the recipient), but does provide certainty to the sender that the recipient alone can decrypt the message.
Mutual certainty can be provided by applying both signing and encrypting. There are different techniques of signing (digital signature) known to counteract intrusion of such communication by unauthorized parties.
(1) User certificates (signing): “The recipient verifies that the message originates from the sender”. Providing certainty to the recipient that the message actually originates from the sender. This is done by encrypting the message with the private key of the sender. Each recipient can decrypt with the public key of the sender (for instance from the latter's user certificate). Signing hence does not provide certainty to the sender that the recipient alone can decrypt the message (anyone can decrypt with the public key of the sender), but does provide certainty to the recipient that the message has been sent by the sender.
(2) Browser certificates. Standard certificates in browsers are not user certificates, but server certificates. With them, the user (U) can check that the server with which he is communicating (C) is actually the server he thinks he is communicating with. These certificates do not provide certainty to the server C that the user U is who he claims to be. For that, the user can be asked to log in at server C, so that such certainty does arise.
In an example of an application to webstores, a user U may, for instance, give instruction to send information from A to B in order to be able to obtain a service from B. The service concerned may depend on personal information about U, such as age, which needs to be retrieved at a trusted party A, such as, for instance, the authorities, or a sufficient bank balance, which needs to be confirmed by a trusted bank A. Technically, this means that B generates a request for information, to which A, by order of U, responds by searching in a database of A for information with an identification of U, after which the information is sent to B in a reply. Statutory regulations on the registration of such data and access thereto (Dutch WBP Act: “Personal Data Protection Act”) set limiting conditions on such a process. For instance, A needs to be entitled to keep the database, and there are limitations circumscribing at whose request and to whom which information may be provided.
Jointly, the use of certification, signing and encryption can ensure that (a) privacy sensitive information can only be requested by an apparatus U (“user”) that can show a certificate proving he has the right to query the information (or demonstrates this right by logging in with a password), (b) it can be verified that the retrieved information has been delivered by an authoritative source A, (c) the recipient of the information is indeed a party B that has been designated for that purpose by U, and (d) that the information can be inspected by B and U alone.
But nonetheless there is some loss of privacy. The apparatus B could, after decryption, register more information than is strictly necessary for the service rendered, which makes abuse possible. Further, in conventional implementations the apparatus A can, on the basis of apparatus B for which the information is intended, register what information for what service-provider has been retrieved for the user U, which entails the possibility of unauthorized use of this information by A (for instance, the authorities or a bank), and in any case violates the privacy of U. This problem can be mitigated by having A provide the information to U alone, and forwarding this information from U to B. But this increases the risk of manipulation of the information and the request therefor. This risk can be reduced by use of a trusted intermediary device C as a proxy for U between A and B. But in this case, too, A could infer more information from the request than is desirable.
In the prior art the so called secure comparison protocol is known, with which also the information exchange between apparatuses A and B can be limited. A secure comparison protocol (also known as a solution of the “millionaires problem”) is an algorithm to compare a first and second number which are respectively known to a first and second party, without either party needing to know both numbers. For examples, see the article “Comparing encrypted data” by T. Veugen, published on http://isplab.tudelft.nl/sites/default/files/Comparing%20encrypted%20data.pdf.
With the secure comparison protocol it can be ensured that the apparatus A at the source of the information and the apparatus B generating the request for the information do not get to know what their information is compared with. A and B in this case see only a part of the result of the comparison. But if A executes the protocol with B, A still learns the identity of B, and hence also learns that for U a particular kind of information for a service associated with B has been requested. U could prevent this by requesting information signed by A and forwarding it to B, but this can be done only if A knew the comparison result. If for the encryption a public key of B is used, A could find out the identity of B on the basis of this public key. Creating keys exclusively for the session leads to overhead. If a proxy C executes the secure comparison protocol on behalf of U with A, then C can get access to confidential results about U from A. Also, if C is not sufficiently trusted, U would not have any certainty that C will not of its own initiative retrieve information about U at A.
It is desirable to provide for a process for sending information that satisfies the following limiting conditions:
1. Between the apparatus A with the information about user U and the apparatus B for which the information is intended, an intermediary device C has to be used that prevents A from being able to register for what apparatus B the information is intended.
2. C may not get access to the information.
3. The user U must first give his permission before the reply to the question may be forwarded by C to B.
4. It is not necessary that U disposes of a certificate or another cryptographic key.
5. Preferably, it is impossible for C on its own initiative to ask A for information and obtain it.
6. The result of the comparison may not become known at apparatus A, but may at B and C.
It is desirable to provide for process steps with which an intermediary device C makes it possible to provide such a process for sending information that satisfies the limiting conditions mentioned.
It is desirable to provide for an intermediary device C that makes it possible to provide such a process for sending information that satisfies the limiting conditions mentioned.
It is desirable to provide for a user device U that makes it possible to provide such a process for sending information that satisfies the limiting conditions mentioned.